Add experimental support for MSC4360: Sliding Sync Threads Extension #19005
Conversation
| ) -> JsonDict: | ||
| """Get related events of a event, ordered by topological ordering. | ||
| TODO Accept a PaginationConfig instead of individual pagination parameters. |
There was a problem hiding this comment.
This has been done already, the comment just wasn't updated.
| async def get_thread_updates_for_user( | ||
| self, | ||
| *, | ||
| user_id: str, | ||
| from_token: Optional[RoomStreamToken] = None, | ||
| to_token: Optional[RoomStreamToken] = None, | ||
| limit: int = 5, | ||
| include_thread_roots: bool = False, | ||
| ) -> Tuple[Sequence[ThreadUpdateInfo], Optional[StreamToken]]: | ||
| """Get a list of updated threads, ordered by stream ordering of their | ||
| latest reply, filtered to only include threads in rooms where the user | ||
| is currently joined. |
There was a problem hiding this comment.
Feels like this should be taking in the list of rooms that are being returned in the Sliding Sync response and only returning updates for those.
There was a problem hiding this comment.
I thought about that, and even tried implementing it.
The problem becomes what should we return as a token that is usable on the /thread_updates endpoint?
I assume we would need to follow the same pattern as the receipts extension and handle initial, live, and previously rooms separately. The options for what token to return for pagination would be either the oldest from the three sets, or the newest from the three sets.
In the case of the oldest, further pagination could result in missing updates between the oldest token and the tokens from the other two sets.
In the case of the newest, further pagination could result in receiving duplicate entries.
Then there is the issue of how would you associate the set of rooms/lists with the token such that using it for pagination on /thread_updates makes sense. And would using the new endpoint update the sliding sync connection state? What if using different rooms/lists on the new endpoint than in sliding sync?
It's not that we couldn't come up with solutions to these things. I just felt they quickly over complicated things.
The overall intention was to just be able to track new events in threads easily and separately from the entire set of events to ensure clients can manage a threads notification center without having to paginate through all of a user's event history since the last time they logged in.
Maybe it's worth the complication to add room/list filtering, but I'm not convinced after having tried to implement it.
There was a problem hiding this comment.
We could implement a bulk
/messagesendpoint, where the client would specify multiple rooms andprev_batchtokens.
Per the above, I think we would probably want to use all of the prev_batch tokens from all of the rooms timeline. Perhaps clunky, but maybe good.
And this also gets around the problem where you can't get to the thread updates that you care about without paginating through the bulk. This way, you can specify the rooms you want to get more thread updates in.
There was a problem hiding this comment.
The code now uses the sliding sync room lists to filter results.
| # Helper function to extract StreamToken from either StreamToken or SlidingSyncStreamToken format | ||
| def extract_stream_token(token_str: str) -> str: |
There was a problem hiding this comment.
Where is this used? Where are we using a SlidingSyncStreamToken for another endpoint?
Just trying to understand the landscape as I think we eventually need this kind of thing (matrix-org/matrix-spec-proposals#4186 (comment))
There was a problem hiding this comment.
It gets used in the /thread_updates companion endpiont #19041
I agree that the compatibility should be specced.
The spec mentions usage of tokens from /sync in the /messages api https://spec.matrix.org/v1.16/client-server-api/#get_matrixclientv3roomsroomidmessages
And the simplified sliding sync MSC says the prev_batch token is compatible with /messages
https://github.com/matrix-org/matrix-spec-proposals/blob/erikj/sss/proposals/4186-simplified-sliding-sync.md
prev_batch -> A token that can be passed as a start parameter to the /rooms/<room_id>/messages API to retrieve earlier messages.
So it seems like the landscape is already leaning in that direction, but maybe hasn't been formalized.
| @@ -0,0 +1 @@ | |||
| Add experimental support for MSC4360: Sliding Sync Threads Extension. | |||
There was a problem hiding this comment.
Also comments on the MSC that may change how we approach things here -> matrix-org/matrix-spec-proposals#4360 (review)
Implements sliding sync extension from: matrix-org/matrix-spec-proposals#4360
Companion endpoint added in #19041
Disclaimer: I used Claude Code in a consultative manner to assist with parts of this PR.
I used it mainly for considering options for the SQL query and to help generate test cases.
Pull Request Checklist
EventStoretoEventWorkerStore.".code blocks.